How to Think
Like a Frog

Network engineers can skip this section. The technical material starts at the Introduction.

The rest of this document is for network engineers. This section is for everyone else. It is shorter than the rest on purpose — you do not need the technical detail to understand what FrogNet does or why you might want one.

A Small Box That Changes What Your Family Can Do

Imagine a small box — about the size of a deck of cards — plugged in at your house. Your mother has one at her house. Your sister has one at her flat in London. Each box costs about what you'd spend on a nice dinner out.

Plug them in and they find each other. You do not configure anything. You do not set up accounts. You do not pick a service plan. The boxes form a private, encrypted network that runs a photo gallery, a family chat, a shared calendar, a bulletin board for sticky notes, a family map that shows where everyone is, and video calling — all on hardware that belongs to your family and nobody else.

Your photos are not on iCloud. Your messages are not on WhatsApp. Your location is not sold to data brokers. Everything stays on your boxes. The only thing that crosses the internet is encrypted traffic that nobody — not your internet provider, not a hacker, not a government — can read, and that does not look like FrogNet to anyone watching.

The ongoing cost is a few dollars a month — a small broker subscription that lets your phones reach the network when you're away from home. That is all. No per-person fees. No storage tiers. No annual price increases. No surprise changes to the terms of service. A small broker subscription, and your family has its own private internet — internationally — for as long as the boxes are plugged in.

The actual cost depends on how the broker is deployed. A typical family network running on a commercial broker service is expected to run a few dollars a month — primarily data transfer for the traffic that crosses the internet between your boxes. A family running the broker on their own hardware (for example, a small server already at home or in an office) pays essentially nothing beyond electricity. Larger or more active networks cost more; the current FrogNet development network, with ten nodes across Seattle, New York, and Amsterdam, running heavy testing traffic, runs about forty dollars a month. A typical Mom-and-family deployment will be on the low end of that range, not the high.

What You Pay Today for the Same Things

Most people are already paying for all of this. They are just paying a different company for each piece, and their data is spread across those companies. Here is what a typical family pays today for the services a single FrogNet box would replace, and what each service costs on FrogNet.

Look at the bottom row. The right side is the whole bill on FrogNet — one broker subscription, for every person in your family, everywhere you live, for as long as the boxes stay plugged in. Your data stays on hardware you own.

The left side is what you already pay — money leaving your household every month, plus a second price that never shows up on the bill: unlimited access to your personal data. The companies in that column read your messages, scan your photos, sell your location, and train their AI on your schedule. You pay them, and then they monetize you on top. FrogNet is the offer to stop paying both prices.

Mom Living Alone

If there is one scenario that explains why this matters, it is this one.

An elderly parent lives alone. You want to know she is okay. The options on the market are not great — cameras she will hate, wearables she will forget, services that charge sixty dollars a month to watch her.

A FrogNet box at her house, with a few small passive sensors, learns her daily patterns. When Mom gets up. When she makes coffee. When she moves through the house. It does not watch her. It does not record her. It notices when the pattern changes. If Mom does not get up at her usual time, the system alerts the family — through the private FrogNet, not through a company's servers. No cameras. No surveillance. Her dignity stays intact. Your peace of mind goes up.

That one use alone is worth the cost of the box.

It Still Works When the Internet Does Not

Every app on your phone assumes the internet is there. When it is not — a storm, a blackout, a rural road with no bars — your apps are useless. You cannot call, text, or check on anyone.

FrogNet does not assume the internet is there. Each box is a complete, self-contained network. If the internet disappears, the box keeps running. If two boxes can see each other by WiFi or Ethernet, they mesh together and share everything — photos, messages, sensor data, GPS positions — with no internet required. When the internet comes back, everything catches up.

This matters most in the moments you cannot plan for: when a hurricane takes out the cell towers, when your kid is at a camp with no coverage, when an ambulance drives through a dead zone with a patient in the back. The same box that handles your family photos in good weather keeps working in bad weather. That is not a feature anyone else offers.

For a longer look at how FrogNet performs in emergencies, see Appendix A at the end of this document.

A Word About Privacy

People ask how FrogNet compares to Signal, or to a VPN. The short answer is that Signal is excellent at what it does, and a VPN is useful for what it does, but neither one does what FrogNet does.

Signal protects the content of your messages from the people carrying them. FrogNet eliminates the carrier. There is nobody in the middle to trust, compromise, or compel. No servers to subpoena. No phone numbers. No accounts. No metadata. And it keeps working when the internet does not.

A VPN is an encrypted tunnel to someone else's building — the cloud, Google, Apple, Meta. Your data still ends up on their servers. A FrogNet is not a tunnel. It is your own building. The services run on your hardware. There is no “other end” where a company has your data. There is no company at all.

What Follows

Everything described above is operational today. FrogNet runs across ten nodes in Seattle, New York, and Amsterdam, with more locations coming online. On April 17, 2026, a collaborator in New York completed the first independent end-to-end closed-loop demonstration — a web application, a sensor, and a physical actuator, all on a WiFi network in New York, coordinating through a database 2,400 miles away in Seattle, entirely over FrogNet's semantic protocol. It is not a prototype. It is not a simulation. It is a production system built over more than a decade by a network architect with fifty years of experience at companies including Boeing, Electronic Arts, Sierra On-Line, Microsoft, and NanoString Technologies.

The rest of this document explains how it works. It describes twelve paradigm shifts — foundational assumptions about how networks have worked since 1969 that FrogNet replaces — followed by a comprehensive inventory of everything FrogNet is and does. If you are not a network engineer, you do not need to read it. If you want to understand why the claims in this section are architectural truths rather than marketing promises, read on.

Every network in existence today was built on a set of assumptions that made sense in 1969. Connectivity is rare and expensive, so design for disconnection tolerance. Memory is scarce, so keep the network stateless. Administrators are available, so require human configuration. The internet is reachable, so treat it as the backbone.

Those assumptions have calcified into orthodoxy. Fifty years of protocol design, tooling, and engineering education have been built on top of them. Nobody questions them because everybody learned from people who learned from people who learned from people who never questioned them either.

FrogNet questions all of them.

This document describes twelve paradigm shifts — foundational assumptions about how networks work that FrogNet replaces with better answers for the environments it actually operates in. It then describes, in detail, everything FrogNet is and does.

Reading this document will not make you a FrogNet engineer. But it will make you think differently about what a network can be — and that is the prerequisite for understanding why FrogNet matters.

FrogNet did not make incremental improvements to existing networking. It went back to first principles and replaced thirteen foundational assumptions with designs that match the actual constraints of the environments it operates in.

The paradigm shifts in this document are not theoretical. They allowed a single programmer, working alone, to develop and validate this entire system — the transport-abstracted fabric, the semantic compression engine, the discovery and routing layer, the transient database, the sensor and AI platform, and a real-time adaptive media plane — from scratch, in less than a year. That is not a claim about unusual talent. It is a claim about the leverage of the ideas. The same work, attempted inside the assumptions these shifts replace, would have required a team and a far longer schedule, because most of the effort in conventional networked systems is spent building and debugging the very machinery these shifts delete: the message-passing, the session state, the consensus, the per-application protocols.

Remove the machinery and one person can hold the whole system in their head.

The author spent years on this problem while still inside the old paradigms and made comparatively slow progress; the leaps came only after letting go of those assumptions. The proof of a paradigm is not that it can be argued for — it is that it lets a small number of people build what used to take many. By that test, these shifts are real.

The following is a comprehensive description of FrogNet's architecture, capabilities, and proven performance characteristics as of April 2026.

Network Foundation

• Transport-agnostic fabric — WiFi, Ethernet, WireGuard, LoRa, narrowband RF, any combination
• Self-forming — nodes discover each other automatically, no configuration required
• Self-organizing — topology managed without human intervention
• Self-optimizing — routing and compression improve as the network learns traffic patterns
• Self-healing — network fragments operate independently, rejoin without reconciliation
• Network-to-network architecture — not device-to-device, entire networks federate
• No central authority — no single point of failure anywhere in the design
• Internet-optional — uses internet when available, operates fully without it
• Federation — even extremely low-speed links cause independent networks to join and behave as one cohesive system

Semantic Compression Engine (BLDC-1)

• Reduces structured HTTP traffic by 93.8% in production
• Supports HTML, XML, JSON, CSV, and plain text natively
• Extensible via OO derivation — new data types added without changing the core
• Template learning — network learns structure of traffic automatically
• SAME/DIFF protocol — unchanged responses collapse to 16 bytes
• Applied at infrastructure layer — zero application changes required
• REST is the native protocol — coordination and data use the same compressed transport
• 44× throughput improvement proven on constrained links (Ethernet-shaped to match narrowband RF: 4800 baud, added jitter, 20% packet loss)
• Parallelization fills dead air between messages — near-100% link duty cycle
• All system-level coordination uses REST — automatically benefits from compression

Node Architecture

• Each node is a complete sovereign network
• Runs DNS, DHCP, Apache web server, MySQL database locally
• Operates fully standalone with zero connectivity
• Meshes automatically when other nodes come into range
• Standard Linux hardware — Raspberry Pi, x86, anything
• Python, PHP, bash — no exotic dependencies

Pond and Chorus Model — Scope as Architecture

FrogNet's scope hierarchy answers a problem that conventional networking solves with a lot of heavier machinery: how do you segment a network without designing the segmentation in advance, and how do you change membership without reconfiguring the members?

Four scopes, nested:

• Self — the node itself. Everything the node can do standalone with no other node reachable. Local web server, local database, local AI, local sensors and actuators. This is the offline-first baseline; every other scope is an enhancement.
• Lillypad — the node plus everything directly attached to it. The sensors on its LAN, the ESP32 sensor and actuator boards talking Bluetooth or WiFi to a Pi Zero worker hanging off the node, the laptops and phones using it as their gateway. The lillypad is what an operator thinks of as “their FrogNet” in the small.
• Chorus — a visibility and routing group inside a pond. Nodes in the same chorus can reach each other; nodes in different choruses on the same pond cannot. Membership is dynamic — a node can be in many choruses at once, each with its own subnet within the pond's address space. Choruses can be public (any pond member can join by name) or invisible (joining requires the name and a password). A chorus is the right shape for a task force: a named group of platforms that need to see each other, formed and dissolved by membership change rather than reconfiguration. Choruses are how segmentation happens — not by VLAN, not by firewall rule, but by membership in a named group.
• Pond — the full network. A pond has a name, a network block, a broker, and a membership list. Nodes register into the pond by knowing its name and the address of its broker. Every pond has an “Entire Pond” chorus that all members are auto-joined to on registration; other choruses are opt-in.

The broker is the keeper of pond and chorus membership. It is never a party to the traffic — on one LAN nodes talk directly and the broker never sees a byte; across the internet the WireGuard tunnels it hands out meet at the broker, which relays the encrypted bytes without being able to read them — but it knows who belongs to what. When a node polls the broker, it gets back its current membership. The node reconciles its local state against that. That is the entire control loop.

Two consequences fall out:

Membership is data, not configuration. Moving a node from one pond to another is a single broker record change. Adding a node to a chorus is a single broker call. There is no “push the new config” step because there is no config to push — the node will read the new truth on its next poll. Pond reassignment on the fly, demonstrated in production this month, is the operational form of this property.

Sensors and actuators live in lillypads, but their data lives in the pond. An ESP32 reading a light level, a MeshTastic-bridged sensor on a ridge with no IP infrastructure of its own, a LoRa endpoint delivering a soil-moisture reading through an RF bridge — all of them write into the transient database through their host node's proxy and become visible across the entire pond instantly. The closed-loop demonstration of April 17, 2026 — a Flask UI in New York, an ESP32 sensor on a Manhattan desk, an ESP32 actuator on the same desk, all coordinating through a database 2,400 miles away in Seattle — is the simplest possible expression of this property. The same pattern scales: dozens of ESP32 boards per lillypad, dozens of lillypads per pond, all writing to one transient database, all visible to every node and every AI on the network simultaneously.

The transports a host node uses to reach other nodes are equally varied. Standard Ethernet and 5 GHz WiFi for short range. WireGuard tunnels over the public Internet when the broker provides a path. A 900 MHz HaLow hat — IEEE 802.11ah on the sub-gigahertz ISM band, rated for approximately two miles in clear air — for long-range, license-free, full-IP links between Pi-class nodes; HaLow presents to Linux as a standard WiFi interface, so FrogNet rides it without any protocol translation. Daniel Tone has driven a HaLow node trunk-mounted through Queens, New York, holding the link continuously across multipath, building occlusions, and the metal enclosure of the vehicle itself. MeshTastic and generic LoRa bridges for sensor data arriving over radios narrower than IP can ride directly. None of the application code knows the difference. None of the pond/chorus logic changes. New transports plug in below the line; the architecture above the line does not move.

Transient Database

The transient database's design lineage traces directly to the real-time data buses used in commercial aviation, specifically ARINC 429 — the broadcast bus that has carried flight-control, navigation, and instrumentation data on commercial aircraft for nearly five decades. ARINC 429 is simple: no store-and-forward, no reconciliation, no message addressing. A transmitter broadcasts current state at a fixed rate, and any subscriber on the bus that needs a given parameter reads it. There is no notion of “delivery” because the bus is always carrying the current truth — if you missed it, the next sample is on its way.

The transient database is that idea projected onto a network. Any node writes its current sensor state into the database. Any reader sees it. No history, no reconciliation on rejoin after a network split, no delivery semantics to negotiate. The database is always carrying the current truth, mesh-wide, and any subscriber that needs a given parameter reads it. ARINC 429 gave commercial aircraft a way to coordinate dozens of independent systems on a shared real-time substrate without requiring any of them to know about each other. The transient database gives FrogNet the same capability across a network.

• Floating MariaDB instance on highest-IP node, recalculated on every merge
• Always available anywhere on the mesh — same address regardless of which node hosts it
• Stores real-time sensor data as generic JSON tuples — any sensor, any type
• Intentionally ephemeral — no reconciliation on split/rejoin, matches the physics
• Network-wide shared scratchpad visible to all nodes simultaneously
• Supports real-time dashboards and AI inference simultaneously
• WellKnownSite table — service discovery without DNS, maps service names to node IPs dynamically

AI Platform

• Local Ollama inference — no cloud, no backhaul required
• Domain-specific models trained for the deployment context
• Reads live sensor data from transient database
• Writes commands back to actuators through the same database
• Sensor-to-actuator loops operate entirely offline
• Online/offline — behaves identically with or without internet
• Multiple AIs can run simultaneously across nodes, sharing the same world state
• Multiple dashboards see the same real-time data simultaneously — no master, no replica

Sensor and Actuator Platform

• ESP32 sensor and actuator boards via Bluetooth, WiFi, or Ethernet
• Pi Zero concentrators aggregate and push to local database
• External mesh radio technologies (Meshtastic, MeshCore, generic LoRa) integrate as data endpoints — their RF bridges write directly into the transient database
• FrogNet can also sit on top of those same mesh radio bearers — the semantic layer riding the RF network as its transport
• Any sensor type — environmental, health, telemetry, structural, agricultural
• Bidirectional actuator control validated end-to-end on April 17, 2026 (Flask UI, sensor board, actuator board, all coordinating through the transient database across a 2,400-mile WAN)
• Real-time ingestion with immediate mesh-wide visibility

Broker and Tunnel System

• StreamingFrog broker manages WireGuard tunnel lifecycle
• Broker is not restricted to any specific infrastructure
• Can run on any internet-connected server
• Can run inside a corporate VPN for fully private tunnel networks
• Can run on any node in the mesh itself
• Bidirectional tunnel management — creation, refresh, teardown
• 256-worker daemon pool for genuine parallel processing

Security Model

• Physical proximity is the first perimeter — must be in range to join
• Network membership is the trust boundary — not per-service credentials
• WireGuard encryption on all tunnels — Curve25519, compact handshake
• Inbound from internet closed by default — nodes don't advertise themselves
• No TLS overhead on internal traffic — eliminated by design, not by omission
• Standard Linux underneath — full ecosystem of security tools available if wanted
• TOFU trust model for script distribution — pins on first contact, rejects on key mismatch
• Ed25519 signatures for mesh-wide script distribution
• Not deployed on amateur (ham) radio bands — FCC Part 97.113(a)(4) prohibits obscured communications, and template-based compression is indistinguishable from a cipher to a listener without the template dictionary. This is a deliberate design constraint, not a limitation.

Wire Protocol (FNW1)

• Custom wire protocol — REQ_FULL, REPEAT, RAW, DIFF, RESP_DIFF, SAME, ERROR, SEQ_RESET, HELLO opcodes
• 4-byte big-endian length prefix on all frames
• Sequence-tagged frames for ordered delivery
• WIRE_VERSION=3, REQ_HASH_LEN=16
• LZ4 smart compression underneath BLDC-1

Management and Operations

• frognet_monitor — real-time dashboard showing all nodes, daemon status, metrics
• Admin API — X-Admin-Key protected PHP endpoint for remote node management
• Admin Android fragment — PIN-gated admin UI within FrogNet Family app
• Admin HTML dashboard — browser-based management at FrogNetAdmin vhost
• Restart individual daemons remotely — tunnel, proxy, daemon independently
• Force merge remotely — trigger sync_interfaces.sh from admin UI
• WiFi reconnection — switch antennas to new endpoints via nmcli through admin API
• frognet-runonce — Ed25519-signed script distribution across mesh via gossip relay
• Metrics pipeline — v5 sensor model, SemanticProxy, SemanticCache, SemanticDaemon sensors
• Unified logging — frognet_log.py, ERR/INFO/DEBUG via FROGNET_LOG_LEVEL
• setup_lillypad.bash — complete node provisioning script

Applications Built on the Platform

• FrogChat — vanilla JS single-file chat app, no dependencies, runs in any browser
• FrogNet Family Android app — Kotlin, GPS tracking, chat, sticky notes, dual-write architecture
• Real-time GPS presence map — all users visible mesh-wide via transient DB
• Voice and video calling — WebRTC P2P for 1:1, Galène SFU for group calls
• Family calendar — CalDAV/CardDAV, mesh-synchronized
• Shared photo gallery — self-hosted, no cloud
• Family wiki — flat-file, runs on any node
• Distributed file sync — transport-agnostic, peer-to-peer
• Wellness monitoring — passive activity signals, anomaly detection, elder care alerts
• Emergency broadcast — mesh-wide alert system, works without internet

Deployment and Distribution

• Passcode system — broker authentication for FrogNet Family tunnels
• NetworkManager fix — dns=default prevents resolv.conf overwrites
• Broker portability — any server, any VPN, any node, no vendor dependency

Intellectual Property Position

• Three issued US patents — storage virtualization, pop-up networking, physical product
• Pop-up networking patent is direct architectural precursor to mesh formation — lineage, not just a filing date
• More than a dozen additional patentable inventions identified in the code — deliberately not filed
• NSF Phase I SBIR invitation in hand — Wireless Technologies topic
• CAGE code 1A5Y5, SAM registered, full awards authority

Proven in Production

• Ten nodes across Seattle, New York, and Amsterdam
• First independent end-to-end closed-loop demonstration completed April 17, 2026 — Daniel Tone (New York) driving a physical actuator in New York from a Flask UI in New York, with all coordination passing through the transient database on SeattleDB, 2,400 miles away, entirely over semantic-compressed HTTP
• Sub-2-second transaction RTT transatlantic over a 4800-baud link with 20% loss
• 93.8% bandwidth reduction on real traffic
• 44× throughput improvement on constrained links
• Active development partner in New York City
• MeshTastic-bridged sensor flow operational — RF-delivered sensor data writes directly into the transient database, validated end-to-end by Daniel Tone in New York
• Mobile HaLow link validated through dense urban driving — Daniel Tone operated a trunk-mounted HaLow node through Queens, New York with no observed link drops, demonstrating continuous mesh participation across multipath, building occlusions, and the metal enclosure of the vehicle
• Emergency-management coordination at emergency operations centers, over WiFi, LoRa, and WireGuard — not on amateur radio bands
• TRL 6–7

These scenarios were referenced in the opening section and are reproduced here for readers who want concrete examples of how FrogNet performs when conventional infrastructure fails. Each one is a deployment pattern the current system supports today, not a future roadmap.

Summer Camp

Your twelve-year-old is at a camp in the mountains. There is no cell service and barely any electricity. The camp does not have commercial internet, but the ranger's station has a long-range LoRa link to a Meshtastic-style RF gateway at the trailhead, and the trailhead has a satellite uplink that comes up for a few hours each evening.

The camp has a FrogNet box. So does your house. For most of the day, the camp's box operates on its own — a local network inside the camp for the staff and kids. When the evening uplink comes up, the camp's box and yours find each other and synchronize everything that happened during the day. Your kid's check-ins, their photos, their GPS dots on the family map — all of it arrives in a single batch that the semantic compression engine sends over the narrow link in a fraction of the bandwidth it would normally take.

You leave a sticky note that says “Grandma says hi.” The camp's box picks it up the next evening. Your kid sees it when they wake up.

Nothing goes through any company's servers. No cell service is required at the camp. The link between camp and home is a few hours of narrowband a day, and FrogNet treats that as perfectly sufficient — because for this kind of family communication, it is.

The Ambulance

A paramedic crew responds to an emergency. They load the patient and begin treatment. Between the scene and the hospital, they pass through areas with no cell coverage. In a conventional system, the data they are collecting — vitals, treatment notes, patient status — cannot reach the hospital until they drive back into cell range. The emergency room gets no warning, no preparation time, no head start on the case.

With FrogNet, the ambulance has a box. The hospital has a box. The boxes connect through whatever path is available — cellular, WiFi hotspots along the route, a commercial narrowband data radio, or even a dedicated LoRa relay. Patient data flows to the hospital in real time when connectivity exists. When it does not, the ambulance's box stores everything locally and transmits the moment a link reappears. The ER sees vitals updating as the ambulance approaches. They are ready before the doors open.

This is not hypothetical architecture. FrogNet's semantic compression engine was specifically designed to deliver full web applications over links as narrow as 4800 baud — slower than a 1990s dialup modem — and has been validated at that rate. It achieves 44× the throughput of conventional protocols on the same physical link by learning the structure of the traffic and transmitting only what has changed. On a steady-state data feed like patient vitals, a 500-kilobyte update collapses to fewer than 150 bytes on the wire. That is small enough to send over almost anything that carries IP.

The Disaster

A hurricane hits the Gulf Coast. Cell towers are down. Power is out. The internet does not exist. First responders from six agencies converge on the area with no way to coordinate because every system they use depends on infrastructure that is no longer there.

Each FrogNet box is a sovereign network. Drop one at the command post, one at the field hospital, one at the staging area, one in each search-and-rescue vehicle. They mesh automatically over WiFi when they are near each other. When they are out of WiFi range, they connect by whatever IP-capable radio is in the truck — commercial narrowband, LoRa, Part 15 ISM-band equipment, or a satellite uplink. Sensor data from the field flows into a shared database that every node on the mesh can see. An AI running on one of the boxes watches the sensor feeds and flags anomalies. Dashboards at the command post show real-time positions of every unit.

None of this requires the internet. None of it requires a cell tower. None of it requires any infrastructure that the hurricane could take out. The FrogNet is the infrastructure, and it came in the back of a truck.

The network grows. When two independent FrogNets come within range of each other, they discover each other and merge into a single, larger network — automatically, with no human intervention. A rescue team from Texas arrives with their own FrogNet. They drive within WiFi range of the command post. The two networks see each other, exchange routing information, and become one. Every node on both sides can now reach every other node. This happens in seconds, without anyone configuring anything.

The same merging works across different transport types simultaneously. The command post connects to the field hospital by Ethernet. The field hospital connects to a remote unit by narrowband radio. A supply convoy connects through a satellite uplink. From the application's perspective, it is all one network. The applications do not know and do not care whether the bytes travel by wire, WiFi, radio, or satellite. FrogNet handles the transport. The applications just work.

Small Business, Farm, and Other Everyday Uses

A small business with three locations and ten remote employees replaces Google Workspace with FrogNet boxes at each office and each home. Internal files, messaging, a company wiki, and sensor monitoring at the warehouse — all running on their own hardware, all private, no monthly per-seat fees, no corporate data passing through anyone else's servers.

A family farm deploys sensor nodes in the fields and a FrogNet box at the farmhouse. Soil moisture, temperature, humidity — all flowing into a local dashboard through a LoRa or Meshtastic RF bridge. A local AI makes irrigation recommendations. None of this requires cell coverage in the field. None of it requires a cloud subscription to view your own sensor data.

Everything described in the main body of this document is operational today. This appendix is different. It describes work in progress — and it does so for two reasons.

The first reason is to introduce SotF-ACP — the Song of the Frogs Adaptive Communications Protocol — a communications protocol that does not stop. SotF-ACP is being built on top of FrogNet to handle the use case that matters most when everything else fails: two people trying to communicate across a link that is degrading toward zero.

The second reason is broader. SotF-ACP is being built on top of an extension point in FrogNet's semantic compression engine that allows entirely new wire protocols to be plugged in as infrastructure — with no application changes, no schema declarations, no per-endpoint configuration. SotF-ACP is the first non-trivial use of that extension point. The story of SotF-ACP is therefore also the story of a generic capability with implications well beyond adaptive media. This appendix tells both stories: the protocol, and the architecture that made the protocol possible.

Conventional communication has two states: working, or dropped. A video call is up, or it ends. A voice call is up, or it ends. A text message goes through, or it queues forever waiting for connectivity that may never come. The user experiences a binary outcome.

SotF-ACP has eight states.

The Idea

If you have ever stood by a frog pond at dusk, you have heard it. One frog calls. Another answers. A third joins. Within seconds the pond is a chorus of dozens of voices, overlapping, layered, continuous. The song is the multitude.

Take any one frog out. The song continues. Take most of them out, and the song continues quieter. Take all but one, and that one still sings — and if anyone is listening, the song is still there. The medium changes. The meaning does not.

That is the shape SotF-ACP is built around. Two users have a conversation. The protocol underneath decides, in real time, what shape of message the current link can carry — full bidirectional video at one end of the spectrum, a single byte-scale heartbeat at the other — and renders it appropriately on the other end. The users experience one continuous conversation. The wire carries whatever it can. When the link improves, the protocol climbs back up. When it gets worse, the protocol slides down. Neither end has to know what level the other is at. The protocol does the translation.

The Eight Levels

The levels span roughly six orders of magnitude of bandwidth. The exact boundaries are still being tuned, but the structure is fixed:

Even at L0, the connection is not “dropped.” It is the smallest possible song.

If anything more is possible, the protocol climbs back up. If even L0 fails — total link loss, full jamming, the radio physically destroyed — that is the only condition under which the conversation actually ends.

How This Differs from Every Other Streaming Protocol

This is the part a video or voice engineer will find most surprising. Every real-time media protocol in widespread use — RTP, WebRTC, SIP, the voice/video stacks that ship in every consumer app — handles a degrading link the same way: fire packets into the network as fast as you can, hope most of them arrive, and patch up the wreckage on the receiving end. UDP is the substrate. Packets are independent. The sender does not know which ones got through. The receiver assembles whatever shows up, runs jitter buffers and packet-loss concealment over the gaps, and renders the result. When the link is good, this works well. When the link degrades, the receiver renders the corruption: blocky video, audio that warbles and drops out, partial frames sewn together from packets that arrived and packets that did not. The picture you see is wrong in ways that are unmistakably “the network is failing.”

Call it the shotgun approach. The sender sprays. The receiver salvages.

SotF-ACP inverts every part of this.

The substrate underneath is TCP — reliable, in-order delivery. Frames arrive complete or they do not arrive at all. There is no such thing as half of a frame reaching the receiver. There is no packet-loss concealment, because there is no packet loss; there is only frame delivery or frame omission, and both are clean.

The decision about what to drop is made at the sender, in real time, based on what the link is telling the kernel right now. When the sender's outbound buffer starts filling — the operating system's explicit signal that the link is saturated — the protocol drops complete frames before they ever cross the wire. Not pieces of frames. Whole frames. The receiver does not have to know a frame was dropped. The next frame that arrives is intact, in order, and renderable on its own.

The user-visible effect on a degrading video call is therefore not corruption. It is reduced frame rate. The picture stays clean; it just updates less often. When the frame rate drops below the threshold where video is useful, the protocol drops to audio-only — but the audio is clean, not glitchy. When the audio bandwidth becomes too much, it drops to compressed voice. When that becomes too much, text. Each transition is a clean handoff to a lower-bandwidth, higher-survivability rendering of the same conversation. At no point does the user see a broken version of the higher level. They see the appropriate level for the link they currently have.

There is a deeper structural difference beneath the clean handoff. In WebRTC and SIP, changing quality means renegotiating the session — a fresh ICE/DTLS/SRTP handshake and a round trip of offer and answer before a single frame flows at the new setting. SotF-ACP keeps the two planes physically apart: the audio and video bytes ride one standing TCP stream opened once at the start of the call, while every control value — which rung each side wants, and where to reach it — lives in shared network memory. Changing quality is therefore a memory write, not a renegotiation. There is no handshake to redo and no session to tear down and rebuild; the next frame simply arrives at the new rung. It is the same shift that runs the rest of FrogNet — memory, not messages — applied to the hardest real-time case.

This matters more than it sounds. A brain can fill in a missing frame but cannot unscramble a half-pixelated one. It tolerates an audio stream that pauses and resumes; it fights one that warbles and clicks. Conventional real-time protocols deliver exactly the kind of degradation human perception handles worst. SotF-ACP delivers the kind it handles best.

What Makes This Possible

SotF-ACP is not a clever protocol bolted onto a fragile stack. It is the direct beneficiary of everything described in the main body of this document. The properties FrogNet has — the same ones that make a 4800-baud link useful for full web applications — are what allow eight levels of graceful degradation to exist at all.

• Transport abstraction (shift 1) means SotF-ACP does not care what carries its frames. A level can fall back to a narrowband radio bearer the moment the WiFi link dies, then climb back when WiFi returns. The protocol does not know or care which transport is underneath.
• Offline-first (shift 2) means presence at L0 is not a special “offline mode” — it is just the lowest level of the same protocol, operating on whatever store-and-forward path can reach the other end.
• Semantic compression (shifts 8 and 9) is what makes L2 and L1 possible at bandwidths where conventional protocols cannot pass anything at all. Text under BLDC-1 collapses to its information content; tokens collapse further. By the time you reach L1, the wire cost is small enough that almost any IP-carrying medium will pass it.
• Parallel processing (shift 10) keeps the wire full. Even at low levels, the link runs at near-100% duty cycle — every byte the channel allows carries useful payload, not idle protocol overhead.
• Networked intelligence (shift 12) means the rendering of incoming frames is a local decision. The receiving end's AI and codec stack reconstruct the appropriate output for the current level using context it already has — voiceprint, recent conversation, identity — without having to receive that context over the wire.

The triggers that move the protocol between levels are primarily local to the sender. The kernel tells the sending process when its send buffer is filling up — the link is saturated — and the level shifts down; when that signal runs clean below the next-higher level's threshold for long enough, the level shifts up. The hysteresis is deliberate — the protocol does not chase noise — but the response to a genuine degradation is fast enough that the user perceives one continuous conversation, not a sequence of cliffs. There is also one deliberate cooperative path, and it is worth being precise about what it is and is not: a receiver on a poor link publishes the level it can sustain into the shared memory both ends already use, and the sender reconciles its output to that published level. This is not a feedback protocol in the traditional sense — there is no request, no reply, no acknowledgment, no round-trip the sender waits on. It is a value left in shared memory that the other side reads on its own clock, exactly like every other piece of coordination in FrogNet. The effect is that the two ends fight a degrading link together rather than the sender guessing alone, without paying for a control channel.

Beyond SotF — The Custom Protocol Architecture

SotF-ACP was possible to build in the first place because FrogNet's semantic compression engine is not a single fixed codec. It is a host for custom wire protocols, and BLDC-1 is the default protocol that rides it. The extension point that BLDC-1 uses is the same one that SotF-ACP uses. Anything else that wants to define its own wire shape can use it too.

The interface a custom protocol has to implement is tiny. Two functions. That is the entire contract:

• encode(payload) → wire_bytes. The proxy hands the protocol the HTTP payload bound for the wire. The protocol returns whatever bytes should actually be transmitted. Nothing about how it produces those bytes is the proxy's concern. The protocol can compress, encrypt, transform, replace, fragment, batch, or invent anything it wants.
• decode(wire_bytes) → payload. The proxy hands the protocol whatever it just read from the wire. The protocol returns the payload that should be delivered into the local HTTP stack. Same freedom: any transformation the protocol chose to apply is invisible to everything above and below.

That is the interface. There is no schema to declare. No callback to register beyond those two functions. No protocol-aware framing the proxy needs to know about. No negotiation handshake the proxy mediates. The custom protocol sees bytes in and produces bytes out. The proxy ferries them. The application never knows the protocol exists.

What can ride this two-function interface is limited only by what someone wants to build. SotF-ACP — adaptive media on a degrading link — is one example. Others, all architecturally possible today without any change to the engine:

• Domain-specific compression. BLDC-1 is excellent on structured text. Medical imaging, scientific instrument data, telemetry from specialized industrial controllers, geospatial tilesets — these have compressibility properties a domain-tuned codec can exploit far more aggressively than a general one. A DICOM-aware custom protocol could deliver medical-imaging payloads at fractions of the wire cost BLDC-1 would.
• Application-layer encryption. WireGuard handles tunnel encryption between FrogNet nodes. A custom protocol can add end-to-end encryption on top of that, so payloads are opaque even to the other endpoints in the mesh, even to the broker, even to the local proxy itself if desired. Useful for regulated industries, fragmented-trust deployments, and any requirement that exceeds what mesh membership alone provides.
• Obfuscation and protocol mimicry. A custom protocol can shape its wire bytes to resemble something else entirely — generic HTTPS, plain TLS application data, a streaming video feed — making the FrogNet traffic indistinguishable to a passive observer from whatever protocol is being mimicked. Useful in adversarial-network environments where the very existence of a particular traffic pattern is itself information you do not want to reveal.
• Format translation. A custom protocol can transform payloads between formats on the wire: HL7 medical records to compact binary, verbose XML to a stripped binary representation, JSON to MessagePack. The application keeps speaking whatever format is convenient. The wire sees whatever format is efficient.
• Tunnel-within-a-tunnel. A custom protocol can carry an entirely different protocol — SIP, MQTT, Modbus, an industrial control bus — through FrogNet's transport, with the FrogNet stack acting as a generic data-link layer for the foreign protocol. This lets non-IP protocols ride FrogNet's mesh as if they had native transport.
• Anything else. The interface imposes no constraints beyond bytes-in / bytes-out. A custom protocol can do work that has no name yet.

The custom-protocol extension architectures that exist elsewhere are all positioned somewhere FrogNet's are not. CORBA interceptors and gRPC middleware are application-layer — the application must opt in, the framework imposes a schema, and the transformation surface is bounded by the framework's protocol model. Custom TCP options and IP protocols are transport-layer — they require kernel support and run head-first into NAT and middleboxes the moment they leave a controlled environment. Service meshes like Istio and Linkerd offer per-service traffic shaping but require sidecars, configuration, and a control plane that is itself a protocol.

FrogNet's custom-protocol architecture has none of those constraints. It is application-transparent. It requires no schema. It runs as infrastructure rather than middleware. It has no opt-in barrier. The application makes ordinary HTTP calls. The proxy hands those calls to whatever protocol is configured to handle them. The protocol does whatever it does. The bytes that result cross the wire. The other end reverses the process. The application sees ordinary HTTP responses.

There is nothing else like this — not as a research artifact, not as a commercial product, not as a standards proposal. The closest comparable architecture is something a team would have to build from scratch, embedded in a custom networking stack. Which is exactly what FrogNet did, and what is now available as an infrastructure capability.

SotF-ACP, the adaptive communications protocol described above, is the first non-trivial proof that this works. It is unlikely to be the last.

What This Means

For a family network, this is a feature people will use rarely and value when they do — the call from the cabin in the mountains that downgrades to text instead of dying, the message from the ambulance that gets through as a token when video cannot.

For a business or institutional deployment, it is the difference between “the link went down” and “the link is degraded but the conversation continues.” Operational coordination does not stop when bandwidth drops.

For deployments where lives depend on the link — first responders, field medics, disaster zones, military units operating in contested environments — it is the architectural answer to a problem the industry has not solved. Every other system in this space treats degradation as a sequence of failure modes to be handled. SotF-ACP treats degradation as a continuum along which communication never stops.

There is one condition under which SotF-ACP cannot help: completely jammed, absolutely no path of any kind between the two endpoints. No protocol can deliver a byte across a link that is carrying zero bytes. But the door at which conventional systems give up — the link is bad, the service is unavailable, the call drops — is several orders of magnitude above the floor SotF-ACP operates at. The space between “this would have been a dropped call” and “completely jammed” is where SotF-ACP lives, and that space is enormous.

Status

The protocol now runs a full adaptive loop with recovery, end to end. The level state machine, the buffer-fill trigger logic, session lifecycle, and per-level rung selection all run cleanly under simulated link degradation, with live two-way video on real hardware. Two advances landed beyond the original prototype. First, degradation is now bidirectional and self-healing: each side steps its own quality down when its link congests and back up after the link has been clean for long enough, with deliberate hysteresis so it settles rather than oscillates. Second, the two ends cooperate to fight a bad link — a receiver whose reception is poor publishes the level it can sustain into the shared memory, and the sender reconciles what it transmits to match, per recipient, so one participant on a jammed link is served a survivable stream while everyone else stays at full quality. This cooperation is written as shared memory, not a control protocol: there is no request and no reply, only a published setpoint each side converges to. The work is being done in the open, on top of the FrogNet stack described in the main body of this document; nothing in SotF-ACP requires anything FrogNet does not already provide — which is the point. What remains before field readiness is honest and specific: serving distinct video tiers to different recipients on the same call (the audio-versus-video survival boundary is live today; finer per-recipient video tiering is proven in simulation but not yet on the live path), and validation on production radios where real loss and latency can be measured rather than modeled. The advantage figures quoted for degraded links are grounded first-order models, not yet field measurements.